| Package | hl7.ehrs.uv.phrsfmr2 |
| Type | Requirements |
| Id | Id |
| FHIR Version | R5 |
| Source | http://hl7.org/ehrs/uv/phrsfmr2/https://build.fhir.org/ig/HL7/phrsfm-ig/Requirements-PHRSFMR2-PH.3.5.3.html |
| Url | http://hl7.org/ehrs/uv/phrsfmr2/Requirements/PHRSFMR2-PH.3.5.3 |
| Version | 2.0.1-ballot |
| Status | active |
| Date | 2025-04-03T15:15:30+00:00 |
| Name | PH_3_5_3_Manage_a_Registry_and_Directory_of_Actors |
| Title | PH.3.5.3 Manage a Registry and Directory of Actors (Function) |
| Experimental | False |
| Authority | hl7 |
| Description | Each individual or entity that accesses the PHR-S should be identified in a directory that contains contact information and specific access rights. |
| Purpose | The PHR Account Holder should have control of who has access to his or her PHR-S. All entities that send information to or request information from the PHR-S should be identified for proper authentication and authorization. The PHR Account Holder may establish specific access rights for each actor or groups such as all emergency room physicians. The list of actors may be used to capture contact information for those without digital capability as well. Potential actors may include but are not limited to: - PHR Account Holder Proxy - Trusted relatives, friends, and caregivers. - Healthcare providers that are part of the Account Holder’s team. - Former providers and new providers not yet seen. - Insurance plans. - Pharmacy Benefits Manager, Pharmacies. - Public health registries. - Other registries including cancer, transplant and research. - Hospitals, laboratories and diagnostic imaging centers. All PHR data is associated with a source and all sources should be identified and maintained as long as the data is maintained. All entities making a request for information or receiving information should be identified. Example(s): Each provider should be registered before being granted access rights to the PHR-S. |
No resources found
No resources found
Note: links and images are rebased to the (stated) source
Each individual or entity that accesses the PHR-S should be identified in a directory that contains contact information and specific access rights.
The PHR Account Holder should have control of who has access to his or her PHR-S. All entities that send information to or request information from the PHR-S should be identified for proper authentication and authorization. The PHR Account Holder may establish specific access rights for each actor or groups such as all emergency room physicians. The list of actors may be used to capture contact information for those without digital capability as well. Potential actors may include but are not limited to:
All PHR data is associated with a source and all sources should be identified and maintained as long as the data is maintained. All entities making a request for information or receiving information should be identified.
Example(s): Each provider should be registered before being granted access rights to the PHR-S.
| PH.3.5.3#01 | SHALL |
The system SHALL maintain a directory of all Authorized PHR Users (e.g., actors or organizations) that have requested or have been granted access to the PHR Account Holder's account including data providers and PHR Account Holder Proxies that supply information for possible import into the PHR-S. |
| PH.3.5.3#02 | dependent SHALL |
The system SHALL conform to section S.1.3 (Manage Health Care Provider Information), S.4.2 (Registry Notification and Management), S.4.3 (Manage Donor Information), S.4.5 (Manage PHR Account Holder Reminder Information Updates), PH.6.6 (Referrals and Referral Process (CC05 mentions a registry that lists people who abuse the healthcare system)) in order for the PHR Account Holder to control access rights to specific sections of the PHR-S for each actor in the directory according to user-preference, organizational policy, and/or jurisdictional law. |
| PH.3.5.3#03 | SHALL |
The system SHALL conform to functions in the Supportive Services Section that manage directory-related and/or registry-related information (e.g., information regarding a provider or a pharmacy). |
FHIR{
"resourceType" : "Requirements",
"id" : "PHRSFMR2-PH.3.5.3",
"meta" : {
"profile" : [
"http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/FMFunction"
]
},
"text" : {
"status" : "extensions",
"div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <span id=\"description\"><b>Statement <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b> <div><p>Each individual or entity that accesses the PHR-S should be identified in a directory that contains contact information and specific access rights.</p>\n</div></span>\n\n \n <span id=\"purpose\"><b>Description <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Informative Content\" class=\"informative-flag\">I</a>:</b> <div><p>The PHR Account Holder should have control of who has access to his or her PHR-S. All entities that send information to or request information from the PHR-S should be identified for proper authentication and authorization. The PHR Account Holder may establish specific access rights for each actor or groups such as all emergency room physicians. The list of actors may be used to capture contact information for those without digital capability as well. Potential actors may include but are not limited to:</p>\n<ul>\n<li>PHR Account Holder Proxy</li>\n<li>Trusted relatives, friends, and caregivers.</li>\n<li>Healthcare providers that are part of the Account Holder’s team.</li>\n<li>Former providers and new providers not yet seen.</li>\n<li>Insurance plans.</li>\n<li>Pharmacy Benefits Manager, Pharmacies.</li>\n<li>Public health registries.</li>\n<li>Other registries including cancer, transplant and research.</li>\n<li>Hospitals, laboratories and diagnostic imaging centers.</li>\n</ul>\n<p>All PHR data is associated with a source and all sources should be identified and maintained as long as the data is maintained.\nAll entities making a request for information or receiving information should be identified.</p>\n<p>Example(s): Each provider should be registered before being granted access rights to the PHR-S.</p>\n</div></span>\n \n\n \n <span id=\"actors\"><b>Actors:</b><br/> ehr</span>\n \n\n \n <span id=\"requirements\"><b>Criteria <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b></span>\n \n <table id=\"statements\" class=\"grid dict\">\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>PH.3.5.3#01</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL maintain a directory of all Authorized PHR Users (e.g., actors or organizations) that have requested or have been granted access to the PHR Account Holder's account including data providers and PHR Account Holder Proxies that supply information for possible import into the PHR-S.</p>\n</div></span>\n \n \n Satisfied by:<ol>\n \n <li><a href=\"https://www.hl7.org/fhir/practitioner.html\">https://www.hl7.org/fhir/practitioner.html</a></li>\n \n </ol>\n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>PH.3.5.3#02</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL conform to section S.1.3 (Manage Health Care Provider Information), S.4.2 (Registry Notification and Management), S.4.3 (Manage Donor Information), S.4.5 (Manage PHR Account Holder Reminder Information Updates), PH.6.6 (Referrals and Referral Process (CC05 mentions a registry that lists people who abuse the healthcare system)) in order for the PHR Account Holder to control access rights to specific sections of the PHR-S for each actor in the directory according to user-preference, organizational policy, and/or jurisdictional law.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>PH.3.5.3#03</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL conform to functions in the Supportive Services Section that manage directory-related and/or registry-related information (e.g., information regarding a provider or a pharmacy).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n </table>\n</div>"
},
"extension" : [
{
"url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-wg",
"valueCode" : "ehr"
}
],
"url" : "http://hl7.org/ehrs/uv/phrsfmr2/Requirements/PHRSFMR2-PH.3.5.3",
"version" : "2.0.1-ballot",
"name" : "PH_3_5_3_Manage_a_Registry_and_Directory_of_Actors",
"title" : "PH.3.5.3 Manage a Registry and Directory of Actors (Function)",
"status" : "active",
"date" : "2025-04-03T15:15:30+00:00",
"publisher" : "EHR WG",
"contact" : [
{
"telecom" : [
{
"system" : "url",
"value" : "http://www.hl7.org/Special/committees/ehr"
}
]
}
],
"description" : "Each individual or entity that accesses the PHR-S should be identified in a directory that contains contact information and specific access rights.",
"purpose" : "The PHR Account Holder should have control of who has access to his or her PHR-S. All entities that send information to or request information from the PHR-S should be identified for proper authentication and authorization. The PHR Account Holder may establish specific access rights for each actor or groups such as all emergency room physicians. The list of actors may be used to capture contact information for those without digital capability as well. Potential actors may include but are not limited to: \r\n\r\n- PHR Account Holder Proxy\r\n- Trusted relatives, friends, and caregivers.\r\n- Healthcare providers that are part of the Account Holder’s team.\r\n- Former providers and new providers not yet seen.\r\n- Insurance plans.\r\n- Pharmacy Benefits Manager, Pharmacies.\r\n- Public health registries.\r\n- Other registries including cancer, transplant and research.\r\n- Hospitals, laboratories and diagnostic imaging centers.\r\n\r\nAll PHR data is associated with a source and all sources should be identified and maintained as long as the data is maintained.\r\nAll entities making a request for information or receiving information should be identified.\r\n\r\nExample(s): Each provider should be registered before being granted access rights to the PHR-S.",
"statement" : [
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "PHRSFMR2-PH.3.5.3-01",
"label" : "PH.3.5.3#01",
"conformance" : [
"SHALL"
],
"conditionality" : false,
"requirement" : "The system SHALL maintain a directory of all Authorized PHR Users (e.g., actors or organizations) that have requested or have been granted access to the PHR Account Holder's account including data providers and PHR Account Holder Proxies that supply information for possible import into the PHR-S.",
"satisfiedBy" : [
"https://www.hl7.org/fhir/practitioner.html"
]
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean" : true
}
],
"key" : "PHRSFMR2-PH.3.5.3-02",
"label" : "PH.3.5.3#02",
"conformance" : [
"SHALL"
],
"conditionality" : false,
"requirement" : "The system SHALL conform to section S.1.3 (Manage Health Care Provider Information), S.4.2 (Registry Notification and Management), S.4.3 (Manage Donor Information), S.4.5 (Manage PHR Account Holder Reminder Information Updates), PH.6.6 (Referrals and Referral Process (CC05 mentions a registry that lists people who abuse the healthcare system)) in order for the PHR Account Holder to control access rights to specific sections of the PHR-S for each actor in the directory according to user-preference, organizational policy, and/or jurisdictional law."
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "PHRSFMR2-PH.3.5.3-03",
"label" : "PH.3.5.3#03",
"conformance" : [
"SHALL"
],
"conditionality" : false,
"requirement" : "The system SHALL conform to functions in the Supportive Services Section that manage directory-related and/or registry-related information (e.g., information regarding a provider or a pharmacy)."
}
]
}
XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.